(via Bnjoroge1): Halve memory-derived warm pool size to prevent OOM during successor prov - #169

Summary

Halves the memory-derived warm pool size to prevent out-of-memory (OOM) conditions during successor provisioning.

Problem

When using a warm pool, each slot may temporarily keep both the current job VM and a provisioning successor VM alive simultaneously. The previous calculation only accounted for the memory needed by the current VMs, not the additional memory required during the provisioning window when two VMs can coexist per slot.

Solution

Modified the warm pool size calculation in RunnerPool::run to divide the memory-derived limit by 2, properly accounting for the worst-case memory usage where each warm slot has both a running VM and a successor being provisioned.

The .max(1) ensures that at least one warm slot remains available even on memory-constrained systems.

Summary by cubic

Prevent OOM during successor provisioning by halving the memory-derived warm pool size. Previously we sized for one VM per warm slot; now we account for a transient second VM and guarantee at least one warm slot.

• Implemented in RunnerPool::run: apply saturating_div(2).max(1) to on_demand_memory_cap(...).
• Effect: memory-capped pools may start fewer warm slots; explicit PRELOOP_RUNNER_POOL_SIZE still overrides.
• Rollout: expect fewer OOMs while provisioning successors; if warm capacity drops too much, set PRELOOP_RUNNER_POOL_SIZE to an explicit value.

^{Written for commit 3a26f43. Summary will update on new commits.}